Attorney Docket No.: CISCO-1818 (032590-091) 

REMARKS 

The Office Action mailed February 1, 2007 has been carefully considered. 
Reconsideration in view of the following remarks is respectfully requested. 

Claims 1-4, 9, 13, 21-24, 26-29, 45-48, 50, 52-55, 57-60, and 62-71 are pending. 
No claims stand allowed. 

Claims 5-8, 10-12, 14-20, 25, 30-44, 49, 51, 56, 61, and 72-74 were previously cancelled, 
without prejudice or disclaimer of the subject matter contained therein. 

Claim 53 has been cancelled, without prejudice or disclaimer of the subject matter 
contained therein. 



The First 35 U.S.C. $ 103 Rejection 

Claims 1, 2, 13, 21, 26, 45, 53-55, 58-60, and 63-71 stand rejected under 35 U.S.C. § 
103(a) as allegedly being unpatentable over Perkins 1 in view of Inoue '819 / 2 further in view of 
Martin et al. 3 among which claims 1, 21, 26, and 45 are independent claims. 4 This rejection is 
respectfully traversed. 

According to the Manual of Patent Examining Procedure (M.P.E.P.), 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must 
be a reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art, not in the applicant's 
disclosure. 5 

Claim 1 



1 U.S. Patent No. 5,159,592 to Perkins . 

2 U.S. Patent No. 6,891,819 to Inoue et al. 

3 U.S. Patent No. 6,614,788 to Martin et al. 

4 Office Action mailed February 1, 2001, p. 2. 
5 M.P,E.P§2143. 
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Claim 1 recites 

A network access server (NAS) providing a user with access and connection to a 
global data communications internetwork, said NAS being capable of 
communicating with a home gateway server (HGS) associated with a home 
domain, said NAS comprising: 

an HGS identifier for identifying the HGS associated with the home domain to 
which the request for an IP address is to be transmitted, wherein the HGS 
identifier is responsive to log-in information provided by the user; 

an IP address requester for requesting an IP address from the HGS, the HGS 
maintaining a pool of IP addresses for allocation to authorized users, said DP 
address requester configured to transmit the user's authentication information 
to the HGS with the request for an IP address from the HGS; 

an IP address relayer for receiving an IP address allocated to the user from the 
HGS and for relaying the allocated IP address to the user; and 

a memory coupled with said IP address requester and said IP address relayer, said 
memory storing an association between an identification of the user and the 
IP address allocated to the user. 

The Examiner states: 

... Perkins discloses a network access server (NAS) providing a connection to a 
user in a data communications network, said NAS being capable of 
communicating with a home gateway server (HGS), said NAS comprising: 

an HGS identifier (pseudo-network number) identifying an HGS to which 
the request for an IP address is to be transmitted wherein the home domain is 
distinct from a domain associated with said NAS (col. 8, lines 45-68); 

an IP address requester for requesting an IP address from the HGS (global 
Gateway or GW) on behalf of a user, without using a tunneling protocol, the 
HGS maintaining a pool of IP addresses for allocation to authorized users 
associated with the NAS (local Gateway or GW) (e.g. abstract; Figures 2-5; col. 
5, lines 50-65); 

an IP address relayer for receiving an IP address allocated to the user from 
the HGS and for relaying the allocated IP address to the user (mobile unit) (e.g. 
abstract; Figures 2-5; col. 5, lines 50-65); and 

a memory coupled with said IF address requester and said IP address 
relayer, said memory storing association between an identification of the user 
and the IF address allocated to the user (col. 5, lines 15-27). 

Perkins does not the HGS identifier is responsive to log-in information 
provided by the user. In analogous art '819 discloses another network access 
server providing a user with access and connection to the internet wherein the 
HGS identifier (i.e. home agent 5) is responsive to log-in information provided 
by the user (i.e. mobile computer 2) (i.e. the user supplies "log-in information" 
such as the home agent identifier, which is then transmitted to the home agent 
server, and then authentication information is exchanged to authenticate the 
user) (col. 8, lines 44-49). It would have been obvious to one of ordinary skill in 
the art to combine the teaching of '819 with Perkins in order to allow the system 
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of Perkins to be compatible with other networks, thereby increasing the range of 
the system of Perkins to be compatible with other networks, thereby increasing 
the range of the system as well as the customer base of which it can service, as 
well as authenticating an individual user who is operating the mobile computer 
when the mobile computer is connected to a visited site network and transmits a 
current location registration message to the home agent as supported by '819 
(col. 2, lines 55-60). 

Perkins in view of '819 do not specifically disclose the log-in information 
is transmitted with the request for an IP address, rather a challenge is sent to the 
mobile agent, and then a response with the log-in information is transmitted 
back to the server. In analogous art, Martin discloses another system for 
allocating IP addresses to users which utilizes RADIUS server to receive a 
request for an IP address, with login information, which then authenticates the 
user, and if the user is authenticated, allocating an IP address for said user 
(Figure 12B; col. 7, lines 45-65). It would have been obvious to one of ordinary 
skill in the art to combine Martin with Perkins and '819 in order to reduce the 
number of messages sent in the system of '819, thereby reducing congestion on 
the network (i.e. instead of sending four separate messages, IP request, 
challenge, response, IP allocation, sending only two messages, IP request with 
password information, response). 6 

The Applicants respectfully disagree for the reasons set forth below. 

Martin et al. Teaches Away From Claim 1 

Claim 1 requires an HGS identifier for identifying the HGS associated with the home 

domain to which the request for an IP address is to be transmitted, wherein the HGS identifier is 

responsive to log-in information provided by the user. Claim 1 further requires the NAS be 

capable of transmitting the user's authentication information to the HGS with the request for an 

IP address from the HGS. Thus, Claim 1 requires that the IP address come from the HGS, and 

that the HGS identifier is responsive to log-in information provided by the user. However, 

Martin et al. teaches log-in subsequent to obtaining an IP address. Martin et al. states: 

Initially, the RADIUS client sends an authorization request for the user to the 
RADIUS front end (RADIUS server). The RADIUS front end then sends an 
LDAP message to the directory service requesting IP address allocation. The 
directory service identifies an unused internet address, returns this as an LDAP 
message to the RADIUS front end and creates or updates an IP address— user 
allocation record in the directory. The RADIUS front end then returns an 



6 Office Action dated February 1, 2007, U 3. 
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authorization response identifying the IP address to the RADIUS client. 
Subsequently, on log on, the RADIUS client sends an accounting message 
(LOGON message) to the RADIUS front end. Subsequently, on log off, the 
RADIUS client sends a further accounting message to the RADIUS front end 
(LOGOFF message) identifying the user. The RADIUS front end then sends an 
LDAP message to the directory service to clear the IP address-user allocation 
record for that user. 7 



For this reason, the 35 U.S.C. § 103 rejection of Claim 1 is unsupported by the art of record. 
Thus, a prima facie case has not been established and the rejection must be withdrawn. 



Martin et al. Does Not Teach Transmitting The User's Authentication Information To The HGS 

With The Request For An IP Address 

Contrary to the Examiner's statement, Martin et al. does not disclose transmitting the 

user's authentication information to the HGS with the request for an IP address. In support of the 

Examiner's statement, the Examiner refers to the following portion of Martin et al. : 

FIG. 12B is a schematic representation of the message exchange where a 
RADIUS server allocates an IP address (compare FIG. 1 1). 
Initially, the RADIUS client sends an authorization request for the user to the 
RADIUS front end (RADIUS server). The RADIUS front end then sends an 
LDAP message to the directory service requesting IP address allocation. The 
directory service identifies an unused internet address, returns this as an LDAP 
message to the RADIUS front end and creates or updates an IP address—user 
allocation record in the directory. The RADIUS front end then returns an 
authorization response identifying the IP address to the RADIUS client. 
Subsequently, on log on, the RADIUS client sends an accounting message 
(LOGON message) to the RADIUS front end. Subsequently, on log off, the 
RADIUS client sends a further accounting message to the RADIUS front end 
(LOGOFF message) identifying the user. The RADIUS front end then sends an 
LDAP message to the directory service to clear the IP address— user allocation 
record for that user. 8 



7 Martin et al. at col. 7 11. 45-65. (emphasis added) 

8 Martin et al. at col. 7 11. 45-65. 
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The portion of Martin et al. cited by the Examiner refers to an "authorization request," which 

apparently is simply a request for an IP address for a particular user. There is no indication that 

the "authorization request" of Martin et al. includes the user's authentication information as 

required by Claim 1. And other portions of Martin et al. indicate that the user's authentication 

information is obtained prior to sending a request for an IP address. Martin et al. states: 

FIG. 9A shows another arrangement where the connection is made via a 
RADIUS front end 134. The combination of the RADIUS front end 134 and the 
directory server 132 forms a RADIUS server 135. This arrangement facilitates 
the user name identification of the user(s) when on the LAN 40. This is because 
the RADIUS server knows a user's name due to the user authentication 
procedure referenced above? 



The "authentication procedure referenced above" in Martin et al. is apparently the following 

portion of Martin et al. : 

On establishment of a connection, the RADIUS client will carry out user 
authentication, using for example a point to point protocol (PPP). The RADIUS 
client will configure the access of users via the modems by interrogating the 
RADIUS server. Typically this will involve interrogating the server for 
passwords for authenticating the user(s). The RADIUS client can also allocate an 
IP address to the user from a pool of available IP addresses 17. Alternatively, the 
RADIUS server could allocate the IP address. The user will typically retain the 
IP address allocated until the user logs off. 10 

9 Martin et al. at col. 6 11. 28-34. (emphasis added) 

10 Martin et al. at col. 4 11. 36-47. 
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As Martin et al. teaches obtaining a user's authentication information prior to sending a request 

for an IP address, Martin et al. cannot be said to disclose transmitting the user's authentication 

information to the HGS with the request for an IP address as required by Claim 1. For this 

additional reason, the 35 U.S.C. § 103 rejection of Claim 1 is unsupported by the art of record. 

Thus, a prima facie case has not been established and the rejection must be withdrawn. 

Independent Claims 21, 26, and 45 

Claim 21 is a method claim corresponding to apparatus claim 1 and thus includes 
limitations similar to Claim 1. Claim 26 is an In re Beauregard claim corresponding to 
apparatus claim 1 and thus includes limitations similar to Claim 1. Claim 45 is a means-plus- 
function claim corresponding to method claim 21 and thus includes limitations similar to Claim 
21 . Claim 1 being allowable, Claims 21, 26, and 45 must be allowable for at least the same 
reasons. 

Dependent Claims 

As to dependent claims 2-4, 9, 13, 22-24, 27-29, 46-48, 50, 52-55, 57-60, and 62-71, the 
argument set forth above is equally applicable here. The base claims being allowable, the 
dependent claims must also be allowable. 

Claims 21. 26. 45, 54-56, 58-60, and 63 

The Examiner states: 

Claims 21, 26, 45, 54-56, 58-60, and 63 are rejected for similar reasons as stated 
above. Furthermore '891 discloses transmitting the user's authentication 
information with the request for an IP address (see rejections above). 1 1 



11 Office Action, 1] 6. 
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The Applicants respectfully submit the Examiner's reference to "'891" is confusing on two 

accounts. First, the Examiner made no previous reference to an "891" reference. The 

Applicants assume the Examiner intended to refer to U.S. Patent No. 6,891,819 to Inoue et al. 

However, the Examiner previously indicated on page 4 of the Office Action that Perkins in view 

of the Inoue et al. '819 patent does not disclose transmitting the user's authentication information 

with the request for an IP address. Clarification is respectfully requested. 

Claims 51 and 53 

The Examiner states: 

... Perkins discloses said IP address requester transmits the user's authentication 
information to the HGS with the request for an IP address (col. 5, line 50 to col. 6, 
line 20). 12 

Claim 51 was previously cancelled without prejudice or disclaimer. And with this 
Amendment, Claim 53 has been cancelled without prejudice or disclaimer, rendering the 
rejection of Claim 53 moot. 

The Second 35 U.S.C. S 103 Rejection 

Claims 3, 9, 23, 28, 47, 57 and 62 stand rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over Perkins in view of Martin et al. and further in view of Holt et al. 13 14 
This rejection is respectfully traversed. 

As to dependent claims 3, 9, 23, 28, 47, 57 and 62, the argument set forth above is 
equally applicable here. The base claims being allowable, the dependent claims must also be 
allowable. 

12 Office Action, 1|7. 

13 U.S. Patent No. 6,070,192 to Holt et al 
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The Third 35 U.S.C. $ 103 Rejection 

Claims 4, 24, and 48 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Perkins in view of Martin in view of Holt et al. as applied to the claims listed 
above, and further in view of Inoue '616 . 15 16 This rejection is respectfully traversed. 

As to dependent claims 4, 24, and 48, the argument set forth above is equally applicable 
here. The base claims being allowable, the dependent claims must also be allowable. 

The Fourth 35 U.S.C. $ 103 Rejection 

Claims 22, 27, 46, and 50 stand rejected under 35 U.S.C. § 103(a) as allegedly being 

unpatentable over Perkins in view of Martin et al. in view of Holt et al. as applied to the claims 
• . . . 1-710 

listed above, and further in view of Reid et al. This rejection is respectfully traversed. 

As to dependent claims 22, 27, 46, and 50, the argument set forth above is equally 
applicable here. The base claims being allowable, the dependent claims must also be allowable. 

In view of the foregoing, it is respectfully asserted that the claims are now in condition 
for allowance. 

Conclusion 

It is believed that this Amendment places the above-identified patent application into 
condition for allowance. Early favorable consideration of this Amendment is earnestly solicited. 

14 Office Action at p. 6. 

15 U.S. Patent No. 6,442.616 to Inoue et al. 

16 Office Action at p. 7. 

17 U.S. Patent No. 6,233,616 to Reid et al. 
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If, in the opinion of the Examiner, an interview would expedite the prosecution of this 

application, the Examiner is invited to call the undersigned attorney at the number indicated 

below. 

The Applicant respectfully requests that a timely Notice of Allowance be issued in this 

case. 

Please charge any additional required fee or credit any overpayment not otherwise paid or 
credited to our deposit account No. 50-1698. 

Respectfully submitted, 

Thelen Reid Brown 
Raysman & Steiner LLP 



Dated: M^0*XO»V 



IT 



David B. Ritchie 
Reg. No. 31,562 



Thelen Reid Brown Raysman & Steiner LLP 

P.O. Box 640640 

San Jose, CA 95164-0640 

Tel. (408) 292-5800 

Fax. (408) 287-8040 



Office Action at p. 8. 
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